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(57) If a CRL is cached for an increased speed of a 
certificate validation process, when a certification au- 
thority issues a CRL in an urgent situation, the accuracy 
of the certificate validation result cannot be secured be- 
cause the cached CRL is not the latest one. This prob- 



lem is solved as follows. When it issues a CRL, the cer- 
tification authority sends a CRL issuance notification to 
certificate validation servers. The certificate validation 
servers that received the CRL issuance notification 
cache the latest CRL. Thus, the accuracy of the certifi- 
cate validation result can be secured. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] The present invention relates to a public key 
infrastructure system comprising a certification authority 
that issues a public key certificate revocation list, a serv- 
erfor certificate validation that verifies a validity of a pub- 
lic key certificate, and a client who uses the certificate 
validation server. 

Description of the Related Art 

[0002] [Patent Reference 1]: US 2002/0046340A1 , 
[Non-Patent Reference 1]: ITU, ITU-T Recommenda- 
tion X.509 "Information technology - Open systems in- 
terconnection - The Directory: Public-key and attribute 
certificate frameworks", ITU, March 2000, p.7-53, and 
[Non-Patent Reference 2]: "GPKI Government Public 
Key Infrastructure interoperability specification" p, 
18-20, 27-29, "online", April 25, 2001 , approved by Ba- 
sic Problem Workgroup, "searched on March 14, 2003", 
Internet <URL: 

http://www.soumu.go.jp/gyoukan/kanri/010514_2.pdf> 
teach CRLs, server models, and public keys. 
[0003] Systems using the public key infrastructure 
(referred to simply as PKI) including a Government Pub- 
lic Key Infrastructure (GPKI), are coming into wide use 
to identify a person who produced an electronic docu- 
ment of interest and guarantee that the electronic doc- 
ument has not been changed or tampered with (see, for 
example, non-patent reference 1). In a PKI-based sys- 
tem, an electronic document is electronically signed by 
a person affixing his or her digital signature using a key 
called a private key, which is owned only by that person 
(referred to as a signatory). When an electronic docu- 
ment with a digital signature is received, the digital sig- 
nature is verified to identify a producer of the electronic 
document and confirm that the electronic document is 
not tapered with. 

[0004] In uses that require a high level of trust, to ver- 
ify a digital signature requires not only verifying the dig- 
ital signature of interest by using a key called a public 
key embodied in a public key certificate (simply referred 
to as a certificate) of the signatory but also checking 
whether or not the certificate of the signatory is a valid 
one for a person who verifies the digital signature (re- 
ferred to as a verifier). To verify whether or not the cer- 
tificate of the signatory is valid for the verifier, it is nec- 
essary to (1) discover a certification path and (2) verify 
the certification path. 

[0005] The certification path is a chain of trust from 
the verifier to the signatory and is expressed in the form 
of a chain of certificates. Where the certification author- 
ities issue certificates to each other, in particular, special 
certificates, called cross-certificates, are issued. When 



nine certification authorities from ^ to 1 9 have a cross- 
certification relationship with one another, as shown in 
Fig. 2, the certification path from a verifier having a cer- 
tificate issued by the certification authority l 2 to a signa- 
5 tory having a certificate issued by the certification au- 
thority I ! is a chain of certificates beginning with a cross- 
certificate 9 18 followed by a cross-certificate 9 68 , a 
cross-certificate 9 46 , a cross-certificate 9 24 , and then fi- 
nally a certificate of the verifier. A method of validating 
10 the certification path discovered in this manner is de- 
tailed in the above non-patent reference 1 . 
[0006] In one of the GPKI specifications, there are de- 
scribed an end entity model and a certificate validation 
server model as models for verifying the validities of cer- 
15 tificates (see, for example, non-patent reference 2), The 
certificate validation server model uses a certificate val- 
idation server that provides a function to perform an on- 
line check on the validity of the certificate concerned on 
behalf of a client. 

[0007] The certificate validation server model has the 
following advantages over the end entity model. First, 
since there is no need to mount a certification path dis- 
covery function on a client, the certificate validation 
server model can make the client signature verification 
program small. Further, because a client trusts the result 
of decision made by the certificate validation server, it 
is possible to flexibly cope with system configuration 
changes by simply changing a setting of the certificate 
validation server. According to the above non-patent ref- 
erence 2, whether a particular certificate is valid or not 
is verified using a certificate revocation list (referred to 
as a CRL) issued by the certification authorities or an 
OCSP responder. 

[0008] Since it is not efficient to retrieve the CRL from 
the certification authority every time a certificate valida- 
tion is performed, the patent reference 1 discloses a 
method whereby the certificate validation server caches 
the certificates, the CRL and the certification path to in- 
crease the speed of the certificate validation process. 
[0009] To verify a digital signature and build a certifi- 
cation path requires obtaining a certificate of the signa- 
tory. 

[0010] The methods of obtaining a signatory certifi- 
cate can be classed largely into two types. 
[0011] One type of method involves a signatory send- 
ing an electronic document signed with a digital signa- 
ture, with a certificate of the signatory to be obtained 
separately. One example of this method concerns a cas- 
er where a signatory sends an electronic document with 
a digital signature along with a URL that indicates the 
location where a certificate for verifying the digital sig- 
nature is stored. With this method, the verifier needs to 
access the location where the certificate is stored (here- 
after referred to as a certificate repository) to obtain the 
certificate. 

[0012] Another type of method involves a signatory 
sending an electronic document with a digital signature 
along with a certificate that is used to verify the digital 
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signature. 

[0013] If a CRL is cached for an increased speed of 
the certificate validation process, when a certification 
authority issues a CRL in an urgent situation, the cached 
CRL is not the latest one any more. The patent reference 
1 does not refer to this point. 

[0014] One method for solving the above-mentioned 
problem to ensure that the certificate validation can be 
performed correctly even when the CRL is issued in an 
urgent situation, involves having the certificate valida- 
tion server periodically access a location where the CRL 
is stored (hereinafter referred to as a CRL repository) to 
check if the CRL is updated . The above-described meth- 
od is further classified into two types. One is to have the 
certificate validation server itself make a check via the 
network and another is to introduce CRL issuance check 
software into the CRL repository. 
[0015] In enhancing the accuracy of the certificate val- 
idation by using the method of periodically checking 
whether or not the CRL is updated, it is necessary to 
shorten an interval between the checks as practically as 
possible. In the method where the certificate validation 
server itself makes a check through the network, how- 
ever, shortening the check interval will give rise to a 
problem of increasing the load of the network. 
[0016] In the method that introduces a CRL issuance 
check program into the CRL repository, on the other 
hand, there is a problem that if an administrator of the 
CRL repository and an administrator of the certificate 
validation server should differ, the installing of the CRL 
issuance check software is not permitted, leaving the 
check unperformable. 

[0017] Further, in an environment where a plurality of 
certificate validation servers exist, all the certificate val- 
idation servers cannot perform the validation process 
with the same accuracy unless they all use the CRL is- 
suance check software introduced into the CRL repos- 
itory. So, if the number of operational certificate valida- 
tion servers is to be increased or reduced, the setting of 
the CRL issuance check software needs to be changed. 
However, if the administrator of the CRL repository and 
the administrator of the certificate validation servers dif- 
fer, it is difficult to flexibly change the number of certifi- 
cate validation servers. 

[001 8] Another problem is that, if the certification path 
is cached but the certification authorities have revoked 
old cross-certificates and issued new cross-certificates, 
it is necessary to build a certification path including the 
new cross-certificates. 

[0019] Further, in an environment in which there are 
a plurality of certificate validation servers, even if the 
plurality of certificate validation servers validate the 
same certificate, each of the certificate validation serv- 
ers performs the certification path discovery and obtains 
the CRL. This raises a possibility of accesses concen- 
trating on a particular CRL repository or on a particular 
certificate repository and also a possibility of an in- 
creased network load. The patent reference 1 does not 



refer to these problems. 

[0020] Further, in the preceding method of obtaining 
the certificate separately, there is a problem that, to re- 
quest the certificate validation server to verify the certif- 
5 icate, the client must first access the certificate reposi- 
tory to obtain the certificate. 

[0021] Under these circumstances, a new technique 
for resolving these problems is being called for. 

10 SUMMARY OF THE INVENTION 

[0022] Viewed from one aspect the present invention 
provides a public key infrastructure system comprising: 
a certification authority having a certificate issuing 

15 means for issuing a certificate and a CRL issuing means 
for issuing a CRL; a certificate repository having a cer- 
tificate storage means for storing the certificate issued 
by the certification authority; a CRL repository having a 
CRL storage means for storing the CRL issued by the 

20 certification authority; a certificate validation server hav- 
ing a certificate validation means for validating the cer- 
tificate, a CRL cache means for caching the CRL re- 
trieved from the CRL repository and a certification path 
cache means for caching a certification path discovered 

25 by the certificate validation means to validate the certif- 
icate; and a client having a digital signature verification 
means for verifying a digital signature and a certificate 
validation request means for requesting the certificate 
validation server to validate the certificate; wherein the 

30 certification authority has a CRL issuance notification 
transmission means for sending to the certificate valida- 
tion server a CRL issuance notification that "a CRL has 
been issued" at the same time that the CRL is issued; 
wherein the certificate validation server has a CRL is- 

35 suance notification reception means for receiving the 
CRL issuance notification from the certification authori- 
ty- 

[0023] In another aspect of the present invention, 
when the CRL issuance notification reception means re- 
40 ceives the CRL issuance notification, the CRL cache 
means of the certificate validation server retrieves the 
CRL newly issued by the certification authority from the 
CRL repository. 

[0024] In another aspect of the present invention, the 
45 certificate validation server has a CRL issuance notifi- 
cation transmission means which, when the certificate 
validation server finds that the CRL has been newly is- 
sued, sends a CRL issuance notification that "a CRL has 
been issued" to other p re-registered certificate valida- 
50 tion servers. 

[0025] In still another aspect of the present invention, 
the certification authority has a certificate issuance no- 
tification transmission means which, when the certifi- 
cate is issued by the certificate issuing means, sends a 
55 certificate issuance notification that "a certificate has 
been issued" to the certificate validation server; the cer- 
tificate validation server has a certificate issuance noti- 
fication reception means for receiving the certificate is- 
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suance notification; when the certificate issuance noti- 
fication reception means receives the certificate issu- 
ance notification, the certificate validation means builds 
a certification path that includes the newly issued certif- 
icate; and the certification path cache means caches the 
certification path. 

[0026] In a further aspect of the present invention, the 
certificate validation server is provided with a certifica- 
tion path transmission means which, when a certifica- 
tion path is discovered, sends the certification path to 
other pre-registered certificate validation servers; and, 
when it receives the certification path from other certif- 
icate validation servers, the certification path cache 
means caches the certification path. 
[0027] In a further aspect of the present invention, the 
client is provided with a certificate acquisition request 
means which asks the certificate validation server to ob- 
tain a certificate necessary to verify a digital signature; 
and the certificate validation server is provided with a 
certificate acquisition means which acquires the certifi- 
cate requested by the client from the certificate reposi- 
tory and, when it is founded valid by the certificate val- 
idation means, sends the certificate to the client. 
[0028] In a further aspect of the present invention, the 
certificate validation server is provided with a means for 
generating a message that "requests the sending of a 
CRL issuance notification"; the certification authority is 
provided with a means for receiving the CRL issuance 
notification request message; and the CRL issuance no- 
tification transmission means of the certification author- 
ity sends the CRL issuance notification to the certificate 
validation server that transmitted the CRL issuance no- 
tification request message to the certification authority. 
[0029] In a further aspect of the present invention, the 
CRL repository is provided with a CRL issuance notifi- 
cation transmission means which, when it is found that 
a new CRL is stored in the CRL repository, sends a CRL 
issuance notification indicating that "a CRL has been is- 
sued" and also with a CRL issuance notification request 
reception means which receives a CRL issuance notifi- 
cation request message that "requests the sending of 
the CRL issuance notification." 
[0030] In a further aspect of the present invention, the 
CRL issuance check software realizes: a means for 
monitoring the issuance of a CRL and, when a new CRL 
is issued, sending a CRL issuance notification; and a 
means for receiving a CRL issuance notification request 
message; wherein the CRL issuance notification trans- 
mission means sends the CRL issuance notification to 
an originating source of the CRL issuance notification 
request message. 

[0031] In a further aspect of the present invention, the 
certificate validation server is provided with a means for 
receiving a CRL issuance notification request message 
generated by the CRL issuance notification request 
generation means. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0032] 

5 Fig. 1 is a schematic diagram showing a system 
configuration of a digitally signed electronic docu- 
ment exchange system that applies one embodi- 
ment of the present invention. 
Fig. 2 is a diagram showing a relationship of cross- 
to certification among certification authorities 1 in the 
embodiment. 

Fig. 3 is a flow diagrams showing operations of the 
embodiment when a CRL 7 is issued. 
Fig. 4 is a flow diagrams showing operations of the 
15 embodiment when a client terminal 5 sends and re- 
ceives an electronic document attached with a cer- 
tificate 509. 

Fig. 5 is a flow diagrams showing operations of the 
embodiment when a client terminal 5 sends and re- 
20 ceives an electronic document not attached with a 
certificate 509. 

Figs. 6 A and B are diagrams showing examples of 
a CRL issuance notification transmission destina- 
tion list 104 and a CRL issuance notification for- 

25 warding destination list 408. 

Fig. 7 is a diagram showing an operation of the dig- 
itally signed electronic document exchange system 
of Fig. 1 when a certificate validation server 4 re- 
quests a certification authority 1 to send a CRL is- 

30 suance notification 8. 

[0033] Claims 8 A and B are diagrams showing an ex- 
ample of a CRL issuance notification request message 
10. 

35 [0034] Claim 9 is a diagram showing a hardware con- 
figuration of each of a certification authority 1, a certifi- 
cate repository 2, a CRL repository 3, a certificate vali- 
dation server 4 and a client terminal 5 shown in Fig. 1. 

40 DETAILED DESCRIPTION OF THE EMBODIMENTS 

[0035] Now, embodiments of the present invention 
will be described by referring to the accompanying draw- 
ings. It should be noted that this invention is not limited 

45 in any way by the example embodiments presented. 
[0036] Fig. 1 shows a configuration of a digitally 
signed electronic document exchange system, which 
embodies the present invention. This system has nine 
certification authorities (CAs) from CA 1 1 to CA 1 9 (gen- 

50 erally referred to as certification authorities 1), a certifi- 
cate repository 2, a CRL repository 3, n certificate vali- 
dation servers from server 4-, to server 4 n (generally re- 
ferred to as certificate validation servers 4), and m client 
terminals from client terminal 5^ to client terminal 5 m that 

55 request the certificate validation servers 4 to validate 
certificates (generally referred to as client terminals 5), 
all interconnected via a network 0. 
[0037] The certification authorities 1 have a certificate 
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issuing function 1 01 to issue certificates 509 to the client 
terminals 5 and store copies of the certificates 509 in 
the certificate repository 2, a CRL issuing function 102 
to issue a CRL 7, a list of revoked certificates 509, and 
store the CRL 7 in the CRL repository 3, a CRL issuance 
notification function 1 03 to send to the certificate valida- 
tion servers 4 a CRL issuance notification 8 that the CRL 
7 was issued, and a CRL issuance notification request 
reception function 105 to receive a CRL issuance noti- 
fication request message 10 that "requests the sending 
of the CRL issuance notification 8." 
[0038] The certification authorities 1 from CA 1 1 to CA 
1 9 issue cross-certificates 9 to one another and there is 
a cross-certifying relationship among them as shown in 
Fig. 2. 

[0039] The certificate repository 2 has a certificate DB 
201 holding the certificates 509, and a certificate DB 
management function 202 to receive the certificates 509 
from the certification authorities 1 , store the certificates 
509 in the certificate DB 201 and search and return a 
specified certificate 509 from the certificate DB 201 . 
[0040] The CRL repository 3 has a CRL DB 301 hold- 
ing the CRLs 7, and a CRL DB management function 
302 to receive the CRLs 7 from the certification author- 
ities 1, store the CRLs in the CRL DB 301 and search 
and return a specified CRL 7 from the CRL DB 301 . 
[0041] The certificate validation servers 4 each have: 

a CRL cache 401 that caches the CRLs 7; 
a certification path cache 402 that caches a certifi- 
cation path used to validate certificates 509; 
a certificate validation function 403 that, upon re- 
ceipt of a request from a client terminal 5, validates 
a certificate; 

a certificate acquisition function 404 that, in re- 
sponse to a request from a client terminal 5, picks 
up a relevant certificate 509 from the certificate re- 
pository 2, validates the certificate 509 by the cer- 
tificate validation function 403 and, when the certif- 
icate 509 is found valid, sends it to the client termi- 
nal 5; 

a CRL management function 405 that acquires a 
CRL 7 from the CRL repository 3 and stores it in the 
CRL cache 401; 

a CRL issuance notification management function 
406 which, when it receives a CRL issuance notifi- 
cation 8 from a certification authority 1 , transfers the 
CRL issuance notification 8 to other pre-registered 
certificate validation servers 4 or to those certificate 
validation servers 4 which requested the transfer of 
the CRL issuance notification 8 by sending the CRL 
issuance notification request message 10; 
a certification path management function 407 which 
caches the certification path built or discovered by 
the certificate validation function 403 in the certifi- 
cation path cache 402, sends the certification path 
to other pre-registered certificate validation servers 
4 and caches certification paths received from other 
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certificate validation servers 4 in the certification 
path cache 402; 

a CRL issuance notification request generation 
function 410 which generates a CRL issuance no- 
5 tification request message 1 0 that requests the cer- 
tification authority 1 to send the CRL issuance no- 
tification 8; and 

a CRL issuance notification request reception func- 
tion 411 which receives the CRL issuance notrfica- 
10 tion request message 1 0 from other certificate val- 
idation servers. 

[0042] The client terminals 5 each have: 

15 an electronic document exchange function 501 to 
exchange electronic documents 6 with other client 
terminals 5; 

a digital signature function 502 which electronically 
signs electronic documents 6 and verifies digital 
signatures affixed on electronic documents 6 re- 
ceived from other client terminals 5; 
a certificate validation request function 503 which 
requests a certificate validation server 4 to validate 
a certificate 509 and receives a result of validation 
from the certificate validation server 4; 
a certificate acquisition request function 504 which, 
when an electronic document 6 is attached with a 
URL, instead of a certificate itself, indicating a stor- 
age location of the certificate 509, sends to a certif- 
icate validation server 4 identification information 
on the certificate to obtain the certificate 509 stored 
at the URL and receives the certificate 509 from the 
certificate validation server 4; 
a private key 508 used by the digital signature func- 
tion 502; and 

a certificate 509 issued by a certification authority 1 . 

[0043] A certificate 509 1 of the client terminal 5 1 is is- 
sued by a certification authority 1 1 and a certificate 509 2 
of a client terminal 5 2 is issued by a certification authority 

[0044] In this embodiment, the certificate validation 
server 4 used by the certificate validation request func- 
tion 503 and the certificate acquisition request function 
504 is a particular certificate validation server 4 prese- 
lected from among the certificate validation servers 4 r 

K 

[0045] For example, the client terminal 5 2 uses a cer- 
tificate validation server 4 V 

[0046] The certification authorities 1, the certificate 
repository 2, the CRL repository 3, the certificate valida- 
tion servers 4 and the client terminals 5 shown in Fig. 1 
can be realized by a CPU 91 executing a certain pro- 
gram loaded on a memory 92 in a general computer 
which comprises, as shown in Fig. 9 for example, the 
CPU 91 , the memory 92, an external storage device 93 
such as a hard disk, a reading device 94 for reading in- 
formation from a removable storage medium 99 such as 
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CD-ROM, a communication device 95 for communicat- 
ing with other devices via a network, an input device 96 
such as keyboard and mouse, an output device 97 such 
as monitor and printer, an interface 98 for transferring 
data between these devices. 5 
[0047] That is, by executing a certain program, the 
CPU 91 can realize, as a process, a certificate issuing 
function 101, a CRL issuing function 102, a CRL issu- 
ance notification function 103, a CRL issuance notifica- 
tion request reception function 105, a certificate DB 10 
management function 202, a CRL DB management 
function 302, a certificate validation function 403, a cer- 
tificate acquisition function 404, a CRL management 
function 405, a CRL issuance notification management 
function 406, a certification path management function 15 
407, a CRL issuance notification request generation 
function 410, a CRL issuance notification request recep- 
tion function 411, an electronic document exchange 
function 501, a digital signature function 502, a certifi- 
cate validation request function 503, and a certificate 20 
acquisition request function 504. Further, a certificate 
DB 201 , a CRL DB 301 , a CRL cache 401 and a certifi- 
cation path cache 402 can be realized by the CPU 91 
using the memory 92 and the external storage device 
63. 25 
[0048] The program to realize these devices on the 
computer may be loaded into the computer from the 
computer-usable removable storage medium 99 
through the reading device 94 or may be introduced 
from other servers through the communication device 30 
96 and a computer-usable communication media such 
as a network or a carrier wave that propagates on the 
network. 

[0049] The program may be temporarily stored in the 
external storage device 93 before being loaded onto the 35 
memory 92 for execution by the CPU 91. Or it may be 
directly loaded onto the memory 92, without being 
stored in the external storage device 93, for execution 
by the CPU 91. 

[0050] Next, an operation of the digital signature- 40 
based system of Fig. 1 will be explained with reference 
to the drawings when the certificate validation server 4 
requests the certification authority 1 to send the CRL 
issuance notification 8. 

[0051] Fig. 7 shows an operation of the certificate val- 45 
idation server 4 and the certification authority 1 in the 
digital signature-based system of Fig. 1 when the certif- 
icate validation server 4 requests the certification au- 
thority 1 to send the CRL issuance notification 8. 
[0052] In the certificate validation server 4, the CRL so 
issuance notification request generation function 410 
generates the CRL issuance notification request mes- 
sage 10 (step 7101) and sends it to the certification au- 
thority 1 (step 7102). 

[0053] The CRL issuance notification request mes- 55 
sage 10 exemplified in Fig. 8A comprises a message 
that "requests the sending of the CRL issuance notifica- 
tion 8" and a hostname which represents an address on 



the network 0 of a destination of the CRL issuance no- 
tification 8. 

[0054] In the certification authority 1, when the CRL 
issuance notification request reception function 105 re- 
ceives a CRL issuance notification request message 10 
(step 7201 ), it adds to a CRL issuance notification trans- 
mission destination list 104 a hostname of the certificate 
validation server 4 that transmitted the CRL issuance 
notification request message 10 (step 7202). 
[0055] When the certificate validation server 4 1 re- 
quests the forwarding of the CRL issuance notification 
8 to the certificate validation server 4 2 , the CRL issu- 
ance notification request generation function 410 of the 
certificate validation server 4^ generates the CRL issu- 
ance notification request message 10 and sends it to 
the certificate validation server 4 2 . 
[0056] The CRL issuance notification request recep- 
tion function 411 of the certificate validation server 4 2 
receives the CRL issuance notification request mes- 
sage 10 and adds the hostname of the originating cer- 
tificate validation server 4 to the CRL issuance notifica- 
tion transmission destination list 104. 
[0057] When the certificate validation server 4 re- 
quests the certification authority 1 to stop sending the 
CRL issuance notification 8, the server sends the CRL 
issuance notification request message 1 0 shown in Fig. 
8B to the certification authority 1. 
[0058] The CRL issuance notification request mes- 
sage 1 0 of Fig. 8B consists of a message that "requests 
the stopping of transmission of the CRL issuance noti- 
fication 8" and a hostname of the destination of the CRL 
issuance notification 8. 

[0059] Upon reception of the CRL issuance notifica- 
tion request message 10 of Fig. 8B, the certification au- 
thority 1 deletes the hostname of the certificate valida- 
tion server 4 from the CRL issuance notification trans- 
mission destination list 104. 

[0060] When the certificate validation server 4 re- 
quests other certificate validation servers 4 to forward, 
or stop forwarding, the CRL issuance notification 8, it 
sends the CRL issuance notification request message 
10 to an intended certificate validation server 4. 
[0061] Next, in the digital signature-based system of 
Fig. 1, the operation of the certification authority 1, the 
CRL repository 3 and the certificate validation server 4 
when a CRL 7 is issued will be explained by referring to 
the drawings. 

[0062] Fig. 3 illustrates the operation of the certifica- 
tion authority 1 , the CRL repository 3 and the certificate 
validation server 4 in the digital signature-based system 
of Fig. 1 when a CRL 7 is issued. 
[0063] First, let us look at the operation of the certifi- 
cation authority 1 . 

[0064] In the certification authority 1, when the CRL 
issuing function 102 generates a CRL 7 (step 3101), it 
sends the CRL 7 to the CRL repository 3 (step 3102). 
[0065] Then, the CRL issuance notification function 
103 generates a CRL issuance notification 8 and sends 
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it to the predetermined certificate validation servers 4 or 
to those certificate validation servers 4 that requested 
the transmission of the CRL issuance notification 8 by 
sending the CRL issuance notification request message 
10 (step 3103). 

[0066] In this embodiment, the certification authority 
1 sends the CRL issuance notification 8 to the certificate 
validation servers 4 whose hostnames are on the CRL 
issuance notification transmission destination list 104. 
[0067] Fig. 6A illustrates an example of a CRL issu- 
ance notification transmission destination list 104 man- 
aged by the certification authority 1 , which shows a host- 
name of a certificate validation server 4 1 and a host- 
name of a certificate validation server 4 n . 
[0068] Thus, the CRL issuance notification function 
103 of the certification authority 1 sends the CRL issu- 
ance notification 8 to the certification validation server 
4^ and the certificate validation server 4 n . 
[0069] Next, the operation of the CRL repository 3 will 
be described. 

[0070] The CRL DB management function 302 of the 
CRL repository 3 waits for an access from the certifica- 
tion authority 1 or the certificate validation server 4. Up- 
on receiving a CRL 7 from the certification authority 1 
(step 3301), the CRL DB management function 302 
stores the CRL 7 in the CRL DB 301 (step 3302) and 
again waits for an access from the certification authority 
1 or from the certificate validation server 4. 
[0071] When it receives a request from the certificate 
validation server 4 to send a CRL 7 (step 3303), the CRL 
DB management function 302 searches through the 
CRL DB 301 for the CRL 7 (step 3304), sends it to the 
requesting server 4 and again waits for an access from 
the certification authority 1 or from the certificate valida- 
tion server 4. 

[0072] Next, the operation of the certificate validation 
servers 4 will be explained. 

[0073] Here, the operation of the certificate validation 
server 4 will be explained by taking as an example the 
operation of the certificate validation server 4 1 when it 
receives the CRL issuance notification 8 from the certi- 
fication authority 1. 

[0074] First, in the certification validation server 4 V 
when the CRL issuance notification management func- 
tion 406 receives a CRL issuance notification 8 from a 
certification authority 1 or any other certificate validation 
server 4 (step 3401), it checks whether it already re- 
ceived the CRL issuance notification 8 (step 3402) and, 
when the CRL issuance notification 8 is found to have 
already been received, exits the processing. 
[0075] When the CRL issuance notification 8 is found 
to be first received, the CRL management function 405 
accesses the CRL repository 3 (step 3403), obtains the 
CRL 7 (step 3404) and caches it in the CRL cache 401 
(step 3405). 

[0076] Then, the CRL issuance notification manage- 
ment function 406 transfers the CRL issuance notifica- 
tion 8 to other pre-registered certificate validation serv- 
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ers 4 or to those servers which requested the transfer 
of the CRL issuance notification 8 by sending the CRL 
issuance notification request message 10 (step 3406). 
[0077] The certificate validation server 4 uses a CRL 

5 issuance notification forwarding destination list 408 to 
manage the certificate validation servers 4 to which the 
CRL issuance notification 8 is to be forwarded. 
[0078] Fig. 6B illustrates an example of the CRL issu- 
ance notification forwarding destination list 408 man- 

10 aged by the certificate validation server 4 1 , which shows 
a hostname of the certificate validation server 4 2 , a host- 
name of the certificate validation server 4 3 and a host- 
name of the certificate validation server 4 n . 
[0079] Therefore, the CRL issuance notification man- 

15 agement function 406 forwards the CRL issuance noti- 
fication 8 to the certificate validation server 4 2 , the cer- 
tificate validation server 4 3 and the certificate validation 
server 4 n . 

[0080] In this embodiment, the hostnames of the cer- 
20 tificate validation servers 4 1 to 4 n are always present in 
one of the CRL issuance notification forwarding desti- 
nation lists 408 held by the certificate validation servers 
4^ to 4 n respectively. 

[0081] With this arrangement, when one of the certif- 
25 icate validation servers 4 receives a CRL issuance no- 
tification 8 from the certification authority 1, the CRL is- 
suance notification 8 can be sent to all the certificate 
validation servers 4^ to 4 n without fail. 
[0082] When a new certificate validation server 4 is to 
30 be added, this can be done without changing the CRL 
issuance notification transmission destination list 1 04 by 
simply adding a hostname of the new certificate valida- 
tion server 4 to one of the CRL issuance notification for- 
warding destination lists 408 held by the certificate val- 
35 idation servers 4 r 4 n 

[0083] Described above is the operation performed by 
the digital signature-based system of Fig. 1 when a CRL 
7 is issued. 

[0084] Next, in the digitally signed electronic docu- 

40 ment exchange system of Fig. 1, the operation of the 
system performed when an electronic document 6 is 
transmitted from a client terminal 5 } to a client terminal 
5 2 will be explained by referring to the drawings. 
[0085] In this embodiment, there are two cases: one 

45 in which the certificate 509 to verify a digital signature 
affixed on the electronic document 6 is attached to the 
electronic document 6; and one in which it is not at- 
tached to the electronic document 6. First, let us look at 
the case where the certificate 509 to validate the digital 

so signature is attached to the electronic document 6. 
[0086] Fig. 4 shows the operation of the client terminal 
5., , the client terminal 5 2 , the certificate validation server 
4) and the certificate validation server 4 2 in the digitally 
signed electronic document exchange system of Fig. 1 

55 when the certificate 509 to validate a digital signature 
affixed on an electronic document 6 sent from the client 
terminal 5 1 to the client terminal 5 2 is attached to the 
electronic document 6. 
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[0087] First, the operation of the client terminal 5^ is 
explained. 

[0088] When the electronic document exchange func- 
tion 501 of the client terminal 5^ generates the electronic 
document 6 for transmission to the client terminal 5 2 
(step 4501), the digital signature function 502 affixes a 
digital signature on the electronic document 6 by using 
the private key 508! (step 4502). 
[0089] Next, the electronic document exchange func- 
tion 501 sends the digitally signed electronic document 
6 along with the certificate 509., to the client terminal 5 2 
(step 4503). 

[0090] Next, the operation of the client terminal 5 2 is 
explained. 

[0091] When the client terminal 5 2 receives the elec- 
tronic document 6 (step 4511), the certificate validation 
request function 503 of the client terminal 5 2 requests 
the certification validation server 4^ to verify the validity 
of the certificate 50^ received along with the electronic 
document 6 (step 4512) and receives a result of the val- 
idation from the certification validation server 4^ (step 
4513). 

[0092] If the result of the validation finds that the cer- 
tificate 509., is not valid for the client terminal 5 2 , the 
terminal ends its processing. 

[0093] If the result of the validation finds that the cer- 
tificate 509i is valid for the client terminal 5 2 the digital 
signature function 502 retrieves a public key from the 
certificate 509! and validates the digital signature af- 
fixed on the electronic document 6 (step 4515). When it 
is decided that the digital signature is not correct, the 
processing is terminated. 

[0094] When the digital signature is found correct, the 
electronic document 6 is stored (step 4516). 
[0095] Next, the operation of the certificate validation 
servers 4 will be described. 

[0096] First, when the certification validation server4 1 
is requested by the client terminal 5 2 to validate the cer- 
tificate 509! (step 4401 ), the certificate validation func- 
tion 403 checks if a certification path from the client ter- 
minal 5 2 to the client terminal 5^ exists in the certification 
path cache 402 (step 4402). 

[0097] If the certification path exists in the certification 
path cache 402, the certificate validation function 403 
moves to a step 4404. If the certification path of interest 
does not exist in the certification path cache 402, the 
certificate validation function 403 discovers the certifi- 
cation path (step 4403) before proceeding to a step 
4404. 

[0098] In the step 4404, the certificate validation func- 
tion 403 retrieves a CRL 7 from the CRL cache 401 and 
checks if the certification path is valid or not. Next, it 
sends the check result to the client terminal 5 2 (step 
4405). 

[0099] If the certification path in question is not a new- 
ly discovered one, the processing is ended. If on the oth- 
er hand the certification path is the one that was newly 
discovered in the step 4403, it is sent to the certificate 
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validation server 4 whose hostname is on a certification 
path transmission destination list 409 (step 4407), be- 
fore terminating the processing. 
[01 00] The certification path transmission destination 

5 list 409 is a list of hostnames of the certificate validation 
servers 4 to which the newly discovered certification 
path is to be transmitted. In this embodiment, the CRL 
issuance notification forwarding destination list 408 is 
also used as the certification path transmission destina- 

10 tion list 409. 

[01 01] Thus, in the step 4407, the certification path is 
sent to the certificate validation server 4 2 , the certificate 
validation server 4 3 and the certificate validation server 

15 [0102] While this embodiment uses the same list as 
the CRL issuance notification forwarding destination list 
408 and the certification path transmission destination 
list 409, the present invention is not limited to this ar- 
rangement and may use different lists. 

20 [0103] When the certificate validation server 4 2 , the 
certificate validation server 4 3 and the certificate valida- 
tion server 4 n receive the certification path from the cer- 
tification validation server 4^ (step 4411), the certifica- 
tion path management function 407 checks if the certi- 

25 fjcation path is cached in the certification path cache 402 
(step 4412). 

[0104] If the certification path is cached in the certifi- 
cation path cache 402, the processing is ended without 
performing anything. If the certification path is not 

30 cached in the certification path cache 402, the certifica- 
tion path management function 407 caches it in the cer- 
tification path cache 402 (step 4413), sends the certifi- 
cation path to the certificate validation server 4 whose 
hostname is on the certification path transmission des- 

35 tination list 409 (step 4414), and then exits the process- 
ing. 

[01 05] While in this embodiment the certification path 
management function 407 of the certificate validation 
server 4 sends/receives and caches the certification 

40 path, the present invention is not limited to this arrange- 
ment. For example, it is possible to have the certification 
path management function 407 send/receive and cache 
certification path information that permits unique identi- 
fication of the certification path or build the correspond- 

45 ing certification path from the certification path informa- 
tion as needed. 

[0106] Described above is the operation of the digit- 
ally signed electronic document exchange system of 
Fig. 1 when a certificate 509 used to verify a digital sig- 

50 nature affixed on an electronic document is attached to 
the electronic document 6 that is sent from the client 
terminal 5^ to the client terminal 5 2 . 
[0107] Next, with reference to the drawings, the oper- 
ation of the digitally signed electronic document ex- 

55 change system of Fig. 1 will be explained for a case 
where the certificate 509 to validate a digital signature 
on an electronic document 6 is not attached to the elec- 
tronic document 6 that is transmitted from the client ter- 
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minal 5 t to the client terminal 5 2 . 
[0108] Fig. 5 shows the operation of the clientterminal 
5^ , the client terminal 5 2 , the certificate validation server 
4 and the certificate repository 2 in the digitally signed 
electronic document exchange system of Fig. 1 when 
the certificate 509 to validate a digital signature affixed 
on an electronic document 6 sent from the client terminal 
5t to the client terminal 5 2 is not attached to the elec- 
tronic document 6. 

[0109] First, the operation of the client terminal 5 1 will 
be explained. 

[0110] When the electronic document exchange func- 
tion 501 of the clientterminal 5 1 generates an electronic 
document 6 to be transmitted to the client terminal 5 2 
(step 5501), the digital signature function 502 affixes a 
digital signature on the electronic document 6 using the 
private key 508! (step 5502). 

[0111] Next, the electronic document exchange func- 
tion 501 transmits the digitally signed electronic docu- 
ment 6 with a URL representing a storage location of 
the certificate 509^ to the client terminal 5 2 (step 5503). 
[0112] While this embodiment transmits a URL repre- 
senting the storage location of the certificate 509 along 
with the electronic document 6, the present invention is 
not limited to this arrangement. For example, it is pos- 
sible to transmit a part of information contained in the 
certificate 509. 

[0113] Next, the operation of the client terminal 5 2 will 
be explained. 

[0114] When the client terminal 5 2 receives the elec- 
tronic document 6 (step 5511), the certificate acquisition ■ 
request function 504 requests the certification validation 
server 4^ to obtain the certificate 509! corresponding to 
the URL transmitted together with the electronic docu- 
ment 6 (step 551 2), and receives a result of the request 
from the certification validation server 4-j (step 5513). 
[0115] If the result of the request does not include the 
certificate 509! , i.e., the certification validation server4 1 
decides that the certificate 509! indicated by the URL is 
not valid for the clientterminal 5 2 , the processing is ex- 
ited. If the result of the request includes the certificate 
509!, tne certificate validation request function 503 re- 
trieves a public key from the certificate 509i to validate 
the digital signature affixed on the electronic document 
6 (step 551 5). Then, if the validation finds the digital sig- 
nature to be not correct, the processing is stopped. If 
the digital signature is found correct, it is stored (step 
5516) before exiting the processing. 
[0116] Next, the operation of the certificate validation 
servers 4 will be described. 

[0117] Upon receiving a request from the clienttermi- 
nal 5 2 to acquire the certificate 509 1 (step 5401), the 
certificate acquisition function 404 of the certification 
validation server 4! accesses the certificate repository 
2 by using the URL sent from the client terminal 5 2 (step 
5402) to obtain the certificate 509! (step 5403). 
[0118] Next, the certificate validation function 403 
checks whether the certificate 509! is va, ' d f° r tne cl ' enl 
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terminal 5 2 (step 5404). 

[01 19] The operation of the certificate validation func- 
tion 403 is the same as that from step 4402 to step 4409 
in Fig. 4 and its explanation is omitted here. 

5 [0120] Ifthe check finds that the certificate 509! is val- 
id for the client terminal 5 2 , the certificate validation func- 
tion 403 generates a result of the request including the 
certificate 509! ( ste P 5405) and sends it to the client ter- 
minal 5 2 (step 5407). If on the other hand it is decided 

10 that the certificate 509, is not valid for the client terminal 
5 2 , the certificate validation function 403 generates a re- 
sult of the request indicating that "the certificate is not 
valid" (step 5406) and sends it to the client terminal 5 2 
(step 5407). 

15 [0121] Next, the operation of the certificate repository 
2 will be explained. 

[0122] Upon receipt of a request from the certification 
validation server 4! to send the certificate 509! (step 
5201), the certificate DB management function 202 
20 searches through the certificate DB 201 for the certifi- 
cate 509! ( s t e P 5202), and sends it to the certificate val- 
idation server 4 (step 5203). 

[0123] Described above is the operation of the digit- 
ally signed electronic document exchange system of 

25 Fig. 1 when a certificate 509 used to verify a digital sig- 
nature affixed on an electronic document is not attached 
to the electronic document 6 that is sent from the client 
terminal 5! to the client terminal 5 2 . 
[01 24] In the digitally signed electronic document ex- 

30 change system of this embodiment, as described 
above, when the certification authority 1 issues a CRL 
7, it sends a CRL issuance notification 8 to certificate 
validation servers 4 whose hostnames are on the CRL 
issuance notification transmission destination list 104, 

35 thus notifying the certificate validation servers 4 that it 
has issued the CRL 7. The certificate validation servers 
4 that have received the CRL issuance notification 8 ac- 
quire the CRL 7 from the CRL repository 3 and cache it. 
[0125] Therefore, ifthe certification authority 1 issues 

to a CRL 7 in an urgent situation, because the CRLs 
cached by these certificate validation servers 4 are the 
latest ones, the accuracy of the validation of the certifi- 
cate 509 can be assured. 

[01 26] Further, in the digitally signed electronic docu- 
45 ment exchange system of this embodiment, the certifi- 
cate validation servers 4 that received the CRL issuance 
notification 8 transfer the CRL issuance notification 8 to 
other certificate validation servers 4 whose hostnames 
are listed in the CRL issuance notification forwarding 
50 destination list 408. 

[0127] Therefore, a new certificate validation server 4 
can be added by simply putting a hostname of the new 
certificate validation server 4 on the CRL issuance no- 
tification forwarding destination list 408 in the certificate 
55 validation server 4 to forward the CRL issuance notifi- 
cation 8 to the new server, without having to change set- 
tings on the side of the certification authority 1 . 
[0128] Further, in the digitally signed electronic docu- 
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ment exchange system of this embodiment, when the 
certificate validation server 4 receives a certification 
path from other certificate validation server 4, it caches 
the received certification path. When it discovers a new 
certification path, the certificate validation server 4 
sends the new certification path to other certificate val- 
idation servers 4 whose hostnames are listed on the cer- 
tification path transmission destination list 409. 
[0129] This arrangement allows the certification path 
to be shared among a plurality of certificate validation 
servers 4, preventing accesses to the certificate repos- 
itory 2 and the CRL repository 3 from becoming concen- 
trated or the load of the network from increasing. 
[0130] Further, in the digitally signed electronic docu- 
ment exchange system of this embodiment, when the 
client terminal 5 receives a URL indicating a storage lo- 
cation of the certificate 509, the client terminal 5, rather 
than accessing the certificate repository 2, requests the 
certificate validation server 4 to obtain the certificate 
509. Only when the certificate 509 obtained from the 
certificate repository 2 is valid for the client terminal 5, 
does the certificate validation server 4 return the certif- 
icate 509 to the requesting client terminal 5. 
[0131] Therefore, the client terminal 5 does not need 
to have the function of accessing the certificate reposi- 
tory 2. 

[0132] While in this embodiment the CRL issuance 
notification 8 only carries information to the effect that 
"a CRL has been issued," the present invention is not 
limited to this arrangement. 

[0133] For example, the CRL issuance notification 8 
may contain a newly issued CRL 7 or information on dif- 
ference between a previously issued CRL 7 and a newly 
issued CRL 7. The CRL issuance notification 8 may also 
contain a list of identification information on newly re- 
voked certificates 509. 

[0134] By putting in the CRL issuance notification 8 a 
newly issued CRL7 itself, information on difference be- 
tween the previously issued CRL 7 and the newly issued 
CRL 7, and a list of identification information of newly 
revoked certificates 509, the certificate validation server 
4 that has received the CRL issuance notification 8 can 
eliminate the step of accessing the CRL repository 3 and 
acquiring the newly issued CRL 7. 
[0135] While in this embodiment the transmission of 
the CRL issuance notification 8 and the reception of the 
CRL issuance notification request message 10 are car- 
ried out by the certification authority 1 . The present in- 
vention is not limited to this arrangement. For example, 
the transmission of the CRL issuance notification 8 and 
the reception of the CRL issuance notification request 
message 10 may be done by the CRL repository 3. 
[0136] Alternatively, CRL issuance check software 
may be introduced into the CRL repository 3 to realize 
a function which monitors the issuance of the CRL 7 
and, when a new CRL 7 is found to be issued, transmits 
the CRL issuance notification 8. The CRL issuance 
check software may also realize the CRL issuance no- 
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tification request reception function. The CRL issuance 
notification transmission function may send the CRL is- 
suance notification to an originating source of the CRL 
issuance notification request message. 
5 [0137] The CRL issuance check software allows the 
use of the certification authority 1 and the CRL reposi- 
tory 3 that have no CRL issuance notification transmis- 
sion function. Further, managing the destinations of the 
CRL issuance notification by the CRL issuance notifica- 
10 tion request reception function can flexibly change the 
number of certificate validation servers even if the ad- 
ministrator of the CRL repository and the administrator 
of the certificate validation servers are different. 
[01 38] With this embodiment, since the CRL issuance 
15 notification 8 is sent from the certification authority only 
to the certificate validation server when it issues a CRL, 
there is no need to check whether a CRL is issued or 
not at predetermined intervals. This reduces the load of 
the network 0. 

[0139] Further, since the CRL issuance notification 8 
is issued by the certification authority 1, if an adminis- 
trator of the CRL repository 3 and an administrator of 
the certificate validation server 4 differ, a high level of 
accuracy of the certificate validation can be assured. 
[0140] Further, since the certificate validation server 
4 can request the transmission of the CRL issuance no- 
tification 8 by sending the CRL issuance notification re- 
quest message 10, it is possible to flexibly change the 
number of certificate validation servers 4 if the adminis- 
trator of the CRL repository 3 and the administrator of 
the certificate validation servers 4 are different. 
[0141] Further, when the certificate validation server 
finds that a new CRL has been issued, it notifies other 
certificate validation servers of the issuance of the new 
CRL. 

[0142] When it is desired to change the certificate val- 
idation servers to which the CRL issuance notification 
is to be sent, the setting of the certificate validation serv- 
er need only be changed, making it possible to flexibly 
change the number of certificate validation servers even 
if the administrator of the CRL repository and the admin- 
istrator of the certificate validation servers are different. 
[0143] Further, when the certificate validation server 
newly discovers a certification path, the new certification 
path is transferred to other certificate validation servers 
so that it can be shared among the servers. This ar- 
rangement therefore prevents accesses to the CRL re- 
pository and the certificate repository from becoming 
overcrowded and the network load from increasing. 
[0144] Further, in a case where a certificate is ac- 
quired independently of an electronic document, the cli- 
ent, rather than accessing the certificate repository to 
obtain the certificate, requests the certificate validation 
server to obtain and validate the certificate. This ar- 
rangement obviates the need for the client to have the 
function of accessing the certificate repository to obtain 
the certificate. 

[0145] This invention, therefore, allows the validation 
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of a certificate to be executed reliably with high accuracy 
and small load. 

[0146] It should be further understood by those skilled 
in the art that although the foregoing description has 
been made on embodiments of the invention, the inven- 5 
tion is not limited thereto and various changes and mod- 
ifications may be made without departing from the spirit 
of the invention and the scope of the appended claims. 

10 

Claims 

* 

1. A public key infrastructure system comprising: 

a certification authority (1) having a certificate 15 
issuing means for issuing a certificate and a 
CRL issuing means for issuing a CRL; 
a CRL repository (2) having a CRL storage 
means for storing the CRL issued by the certi- 
fication authority; and 20 
a certificate validation server (4) having a cer- 
tificate validation means for validating the cer- 
tificate and a CRL cache means for caching the 
CRL retrieved from the CRL repository; 

25 

wherein the certification authority has a CRL 
issuance notification transmission means which, 
when the certification authority issues the CRL, 
sends to the certificate validation server a CRL is- 
suance notification that "a CRL has been issued"; 30 

wherein the certificate validation server has a 
CRL issuance notification reception means for re- 
ceiving the CRL issuance notification from the cer- 
tification authority. 

35 

2. A public key infrastructure system according to 
claim 1, wherein, when the CRL issuance notifica- 
tion reception means receives the CRL issuance 
notification, the CRL cache means of the certificate 
validation server retrieves the CRL newly issued by *o 
the certification authority from the CRL repository. 

3. A public key infrastructure system according to 
claim 1 or 2, wherein the certificate validation server 
has a CRL issuance notification transmission 45 
means which, when the certificate validation server 
finds that the CRL has been newly issued, sends a 
CRL issuance notification that "a CRL has been is- 
sued" to other pre-registered certificate validation 
servers. so 

4. A public key infrastructure system comprising; 

a certificate validation server having a certifi- 
cate validation means for validating a certificate 55 
and a certification path cache means for cach- 
ing a certification path discovered by the certif- 
icate validation means to validate the certifi- 
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cate; and 

a client having a digital signature verification 
means for verifying a digital signature and a 
certificate validation request means for re- 
questing the certificate validation server to val- 
idate the certificate; 

wherein the certificate validation server has a 
certification path transmission means which, when 
the certification path is discovered, sends the certi- 
fication path to other pre-registered certificate vali- 
dation servers; 

wherein the certification path cache means 
caches the certification path when it receives the 
certification path from other certificate validation 
servers. 

5. A public key infrastructure system comprising: 

a certification authority having a certificate is- 
suing means for issuing a certificate; 
a certificate repository having a certificate stor- 
age means for storing the certificate issued by 
the certification authority; 
a certificate validation server having a certifi- 
cate validation means for validating the certifi- 
cate; and 

a client having a digital signature verification 
means for verifying a digital signature and a 
certificate validation request means for re- 
questing the certificate validation server to val- 
idate the certificate; 

wherein the client has a certificate acquisition 
request means for requesting the certificate valida- 
tion server to obtain the certificate necessary for 
verifying the digital signature; 

wherein the certificate validation server has a 
certificate acquisition means which retrieves the 
certificate requested by the client from the certifi- 
cate repository and, when the certificate is found 
valid by the certificate validation means, sends the 
certificate to the client. 

6. A certification authority comprising: 

a certificate issuing means for issuing a certifi- 
cate; 

a CRL issuing means for issuing a CRL; and 
a CRL issuance notification transmission 
means for sending to a certificate validation 
server a CRL issuance notification that "a CRL 
has been issued" at the same time that the CRL 
is issued. 

7. .A certificate validation server comprising: 

a certificate validation means for validating a 
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certificate; 

a CRL cache means for caching a CRL; and 
a CRL issuance notification reception means 
for receiving a CRL issuance notification indi- 
cating that a CRL has been issued. 5 

8. A certificate validation server according to claim 7, 
wherein the CRL cache means of the certificate val- 
idation server, when the CRL issuance notification 
reception means receives the CRL issuance notifi- 10 
cation, acquires the newly issued CRL. 

9. A certificate validation server according to claim 7 
or 8, further comprising a CRL issuance notification 
transmission means which, when the certificate val- is 
idation server finds that the CRL has been newly 
issued, sends a CRL issuance notification that "a 
CRL has been issued" to other pre-registered cer- 
tificate validation servers. 

20 

10. A certificate validation server comprising: 

a certificate validation means for validating a 
certificate and a certification path cache means 
for caching a certification path discovered by 25 
the certificate validation means to validate the 
certificate; and 

a certification path transmission means for, 
when the certification path is discovered, send- 
ing the certification path to other pre-registered 30 
certificate validation servers; 

wherein the certification path cache means 
caches the certification path when it receives the 
certification path from other certificate validation 35 
servers. 

11. A client device comprising: 

a digital signature verification means for verify- *o 
ing a digital signature; 

a certificate validation request means for re- 
quest a certificate validation server to validate 
the certificate; and 

a certificate acquisition request means for re- *5 
questing the certificate validation server to ac- 
quire the certificate necessary for verifying the 
digital signature. 

12. A certificate validation server comprising: 50 

a certificate validation means for validating a 
certificate; and 

a certificate acquisition means for acquiring the 
requested certificate from a certificate reposi- 55 
tory and, when the certificate is found valid by 
the certificate validation means, sending the 
certificate to a requesting client. 
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13. A public key infrastructure system according to 
claim 1, wherein the certificate validation server has 
a CRL issuance notification request generation 
means for generating a CRL issuance notification 
request message; 

wherein the certification authority has a CRL 
issuance notification request reception means for 
receiving the CRL issuance notification request 
message; 

wherein the CRL issuance notification trans- 
mission means of the certification authority sends 
the CRL issuance notification to the certificate val- 
idation server that sent the CRL issuance notifica- 
tion request message to the certification authority. 

14. A public key infrastructure system according to 
claim 13, wherein the certificate validation server 
has 

a CRL issuance notification request reception 
means for receiving the CRL issuance notification 
request message from other certificate validation 
servers, and 

a CRL issuance notification management 
means for, when the certificate validation server re- 
ceives the CRL issuance notification, forwarding 
the CRL issuance notification to the certificate val- 
idation server that sent the CRL issuance notifica- 
tion request message. 

1 5. A certification authority according to claim 6, further 
comprising a CRL issuance notification request re- 
ception means for receiving a CRL issuance notifi- 
cation request message; wherein the CRL issuance 
notification transmission means sends the CRL is- 
suance notification to an originating source of the 
received CRL issuance notification request mes- 
sage. 

16. A certificate validation server according to claim 7, 
further comprising a CRL issuance notification re- 
quest generation means for generating a CRL issu- 
ance notification request message. 

17. A certificate validation server according to claim 7, 
further comprising: 

a CRL issuance notification request reception 
means for receiving the CRL issuance notifica- 
tion request message from other certificate val- 
idation servers; and 

a CRL issuance notification management 
means for, when the certificate validation serv- 
er receives the CRL issuance notification, for- 
warding the CRL issuance notification to the 
certificate validation server that sent the CRL 
issuance notification request message. 

18. A CRL repository comprising: 
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a CRL storage means for storing a CRL issued 

by a certification authority; and 

a CRL issuance notification transmission 

means for sending a CRL issuance notification 

when the CRL storage means stores the new 5 

CRL 

19. A CRL repository according to claim 18, further 
comprising: 

10 

a CRL issuance notification request reception 
means for receiving a CRL issuance notifica- 
tion request message; 

wherein the CRL issuance notification trans- is 
mission means sends the CRL issuance notification 
to an originating source of the received CRL issu- 
ance notification request message. 

20. CRL issuance check software realizing in a compu- 20 
ter: 



a CRL issuance notification transmission 
means for monitoring an issuance of a CRL 
and, when a new CRL is issued, sending a CRL 25 
issuance notification; and 
a CRL issuance notification request reception 
means for receiving a CRL issuance notifica- 
tion request message; 

30 

wherein the CRL issuance notification trans- 
mission means sends the CRL issuance notification 
to an originating source of the received CRL issu- 
ance notification request message. 

35 

21 . A CRL issuance notification data format for notifying 
that "a CRL has been issued", including: 



an item describing a newly issued CRL itself; 
and/or *o 
an item describing information on a difference 
between a previously issued CRL and a newly 
issued CRL; and/or 

an item describing a list of identification infor- 
mation on a newly revoked certificate. 
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